AD - Proxmox -> Unprivileged LXC Workaround

About

Upon joining a host to the Active Directory domain, it was impossible to SSH in as one of my domain users. This is due to the misaligned uid and gid mapping between Proxmox and the high uid and gid used by sssd.

Referencing the Proxmox VE documentation: https://pve.proxmox.com/wiki/Unprivileged_LXC_containers

You’ll note that when a Linux Container is unprivileged, root in the container uid: 0 and gid: 0 is mapped to a high uid and gid on the host, so that if a container escape were to occur, it would only yield a shell in an privileged user session.

SSSD High UID and GID Mapping

If you look in /etc/subuid and /etc/subgid on the PVE host, you’ll note the syntax of:

root:100000:65536

Referencing man subuid, you’ll note that this indicates that starting from UID / GID 100000, there can be 65,536 mappings for the root user; effectively 100000 -- 165535. This is defined for root, as this is the default user when a new Linux Container is created.

The Problem

The problem here is that the uid and gid mappings used by sssd when syncing domain users and groups are higher than the 1000000 id in the original config.

The Solution

We should allow a higher subordinate user and group ID mapping, so that the domain-joined Linux Container can map the user IDs appropriately and allow logins.

Note

In the screenshot, the output of the command id domain.admin@ad.lab indicates the uid of 519801105 and the gid of 519800513, 519800512, 519800572 for this particular user.

I’m using the root:500000000:99999999 and not a much higher range like you might see here, for example:.

About the above note

There’s nothing wrong with using a high value as shown in this example. I simply didn’t need it, because the range I chose is sufficienlty large enough to cover the uidand gid output as shown in the id domain.admin@ad.lab command. 

The uid and gid ranges are going to vary between Active Directory environments. So, before you apply the solution, understand the necessary range as required by your environment by inspecting users and groups using the id command on your Linux

Run these commands on the PVE node. The syntax 50000000:9999999 indicates that we’ll have a range of available for user and group IDs spanning 50000000 -- 59999998.

cp /etc/subuid /tmp/subuid.bak
cp /etc/subgid /tmp/subgid.bak
echo 'root:500000000:99999999' >> /etc/subuid
echo 'root:500000000:99999999' >> /etc/subgid

One more piece to the puzzle yet… We need to tell the Linux Container that it should use this mapping, while still continuing to use its original mappings for the root user.

container_id=184
cp "/etc/pve/lxc/$container_id.conf" "/tmp/$container_id.conf.bak"
echo 'lxc.idmap = u 0 100000 65536' >> "/etc/pve/lxc/$container_id.conf"
echo 'lxc.idmap = g 0 100000 65536' >> "/etc/pve/lxc/$container_id.conf"
echo 'lxc.idmap = u 500000000 500000000 99999999' >> "/etc/pve/lxc/$container_id.conf"
echo 'lxc.idmap = g 500000000 500000000 99999999' >> "/etc/pve/lxc/$container_id.conf"
pct reboot $container_id

The u 500000000 500000000 99999999 and g 500000000 500000000 99999999 syntax indicates that any user or group starting with the ID of 500000000 should begin using the mappings.

---

If everything is working, clean up your backed up files:

rm /tmp/subuid.bak
rm /tmp/subgid.bak
rm "/tmp/$container_id.conf.bak"